IBIS Macromodel Task Group Meeting date: 31 August 2021 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis Jared James Google: Zhiping Yang Intel: Michael Mirmak Kinger Cai Alaeddin Aydiner Keysight Technologies: * Fangyi Rao Radek Biernacki Ming Yan Todd Bermensolo * Rui Yang Luminous Computing David Banas Marvell Steve Parker Mathworks (SiSoft): * Walter Katz Mike LaBonte Micron Technology: Randy Wolff Justin Butterfield Missouri S&T Chulsoon Hwang Siemens EDA (Mentor): * Arpad Muranyi Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad asked whether we should cancel the meeting scheduled for September 7th because of the long Labor Day weekend. Ambrish moved to cancel the meeting. Curtis seconded. There were no objections. There will be no meeting on September 7th, and the next meeting will occur on September 14th. - Walter said that if we had any time available at today's meeting he would review his DesignCon IBIS Summit presentation on some new IBIS AMI investigations. ------------- Review of ARs: - Fangyi send BIRD211.3 to ATM. - Done. - Randy to upload BIRD211.3 to the Open Forum website and send an email announcement. - Done. - Walter to send BIRD213.1 draft 6 to ATM. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the August 24th meeting. Walter moved to approve the minutes. Bob seconded the motion. There were no objections. ------------- New Discussion: PAMn BIRD213.1 draft6: Walter said there were no new updates, and he shared the latest draft. Ambrish said he had reviewed last week's minutes, and he asked to confirm that we had decided to change the PAM_Thresholds Reserved Parameter back to required. Fangyi said this was true. Walter said PAM_Thresholds is required if Modulation_Levels is specified. Ambrish asked what happens if the model maker (model) doesn't have the threshold information. He said if a model just inserts PAM_Thresholds to comply with a requirement in the specification, then you might get simple static thresholds or some other form of poor-quality thresholds. He said you might have a case where the EDA tool could do an even better job. Walter said he was willing to consider making them optional, but he noted that every PAM3 designer he had spoken with thought it would be silly to write a model and not know what the thresholds are. Arpad said this discussion reminded him of the original discussion about the clock_times function parameter. During that discussion, we had decided that it would be optional for the model to return clock ticks, and the EDA tool could figure out the clock ticks if the model didn't return them. Arpad said he wished we hadn't made that decision, because the clock ticks the tool determines might not match what the hardware would do. For the same reason, wouldn't it be better to require the model to return the threshold values in this case? Fangyi said that as a practical matter nearly all models have to know their clock ticks and thresholds, or they couldn't implement a slicer and DFE, for example. Ambrish said not all models may have an FFE or other features that require them to know clock ticks and thresholds. To get everyone's opinions and resolve the issue with a vote, Walter moved to change the PAM_Thresholds parameter back to optional. Ambrish seconded. The roll call vote was: Ansys - No Cadence - Yes Keysight - No Mathworks - No Siemens - No Teraspeed Labs - No Zuken - No The motion failed with 1 Yes vote and 6 No votes. The PAM_Thresholds Reserved Parameter will remain required if the Modulation_Levels Reserved Parameter is specified. Walter then discussed PAM_Offsets. He said this Reserved Parameter was optional, but he suggested we could simplify the Required: language from: No, and illegal before AMI_Version 7.2 or if Modulation_Levels is not specified. to: No, and illegal if Modulation_Levels is not specified. Fangyi, Bob and Curtis all said they agreed with this change. The "illegal before AMI_Version 7.2" is implicit because Modulation_Levels is illegal before AMI_Version 7.2. Bob asked if we intend to replace the bit_time parameter in AMI_Init with symbol_time. Arpad said he had written a BIRD draft for that name change and planned to discuss it at the next Editorial task group meeting. He said he had searched IBIS 7.0 for "bit_time", "bit time", "symbol_time", "symbol time" and "UI" and tried to make all the appropriate changes. He noted that we had decided in last week's ATM meeting that the name symbol_time would be more appropriate because it applies to all Modulation_Levels, where bit_time is only the correct name for NRZ. Bob suggested that we leave it to the Editorial task group to discuss the BIRD. He said Arpad's draft was extensive and covered several sections. Walter said he had reviewed Arpad's draft carefully and agreed with all of its changes. Walter showed the bit_time description modifications in BIRD213.1 draft 6 and said that they would probably go away if Arpad's symbol_time BIRD gets folded into 7.1. Bob noted one other editorial question. In this BIRD and the existing IBIS 7.0, he suggested "were it to exist" is not necessary in the sentence: In such a case, the output waveform is expected to be the equivalent waveform that would exist at such a node were it to exist. Walter's "Next Generation IBIS-AMI Modeling" Summit presentation: Walter reviewed his presentation from the recent DesignCon and EMC+SIPI IBIS Summits. https://urldefense.proofpoint.com/v2/url?u=http-3A__ibis.org_summits_&d=DwIGAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=DcQR-qLpQg5lIreuM6-NYECRIAFXt268PRNS5WO043M&m=uTKOIOKiiaWMpQ6aUmojQaGe8sRY0fAsmR6L8giDFNY&s=9wFz0W33GovB_a-BbckSVmgSNgxhI5nKwhh-0xoJ36s&e= https://urldefense.proofpoint.com/v2/url?u=https-3A__ibis.org_summits_aug21b_m081921.pdf&d=DwIGAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=DcQR-qLpQg5lIreuM6-NYECRIAFXt268PRNS5WO043M&m=uTKOIOKiiaWMpQ6aUmojQaGe8sRY0fAsmR6L8giDFNY&s=-nIDz2hvAFgZcx-TEcU--hftfut_IkHsZy7G3U_kUJ8&e= (minutes from DesignCon Summit) https://urldefense.proofpoint.com/v2/url?u=http-3A__ibis.org_summits_aug21b_summit-5Frecording.mp4&d=DwIGAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=DcQR-qLpQg5lIreuM6-NYECRIAFXt268PRNS5WO043M&m=uTKOIOKiiaWMpQ6aUmojQaGe8sRY0fAsmR6L8giDFNY&s=_QgR-yPUESWVn3NisuC1lexSEAViSpwjBBLpexfpn-U&e= - (Walter's presentation - Start time: 3:38:50, Duration: 32:00) https://urldefense.proofpoint.com/v2/url?u=https-3A__ibis.org_summits_aug21b_katz.pdf&d=DwIGAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=DcQR-qLpQg5lIreuM6-NYECRIAFXt268PRNS5WO043M&m=uTKOIOKiiaWMpQ6aUmojQaGe8sRY0fAsmR6L8giDFNY&s=qHmxogF_BNPs5fiVLJegbRj6SgMMJn8B8U-oB-sDjJI&e= Crosstalk Cancellation: Walter again reviewed his investigations into modeling crosstalk cancellation technology. He described a scenario where the hardware Rx and the model each receive their primary channel (e.g., DQ1) and their aggressor channels (e.g., DQ0 and DQ2). The investigation was concerned with FEXT and used the strict definition of FEXT from 802.3. He said the assumption in that case is that the IR of the victim channel and the aggressor channels are the same. If we were to deviate from that assumption, then we would need to add extra columns to the impulse_matrix for AMI_Init. Supporting this in time domain would require a BIRD to allow the aggressor waveforms to be passed to AMI_GetWave. Walter said the investigation used an ideal lossy channel. Crosstalk cancellation applies a filter to the aggressor waveform to represent the crosstalk coupling, then subtracts the result from the primary channel to minimize crosstalk. Walter noted that real crosstalk cancellation circuits and real channels often aren't so nice. He said his investigation produced a nice tool to evaluate crosstalk cancellation possibilities in a special application, but the techniques might not be ready for general use. Training Algorithms: Walter noted that we now have statistical and time domain BCI. However, there is still a need for search algorithms to find the optimal solution in the space of the various parameters and settings. Walter used channel and package models from the 802.3ck site, including cables, long channels, short channels, etc. He presented results from various search algorithms using COM as a metric for different channels. One of the methods, "Genetic" was a variant of genetics based algorithms that Walter developed so it could fit in the firmware of an Rx. Wei-hsing said the ck workgroup publishes COM, and their prescribed optimization scheme uses an exhaustive search over Tx FFE and Rx CTLE combinations along with a local optimization of Rx FFE and DFE (1 tap) at each of those combinations. He asked how Walter's search algorithm results (maximizing COM) over the entire space compared with the results of the COM prescribed optimization approach. Walter said we are entering a period of fundamental change in high-speed Rx design. He said traditionally we have relied on self-optimizing Rx devices created by talented SERDES designers who are experts in analog transistor design. He said this approach totally fails at 112Gbps. Instead, they now have to make devices where the incoming signal goes through a CTLE and then is digitized (you need 4 separate A to D converters to break up the task and work on different symbols at 112Gbps, because a single A to D isn't fast enough). You need pipelined processors to handle all the FFE taps, and you only have time for one DFE tap. He said these devices can't self-optimize and are beyond the realm of a talented SERDES designer. These must be implemented in software, and they must be optimized by a training process. This will be a real challenge for the industry. Walter referred to slide 27 in the presentation, and noted that you don't get a traditional eye diagram. You really only get to see one sample per symbol. Ambrish agreed that you just get one "center" sample. Walter said EDA tool analysis of waveforms will be totally different. - Walter: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 14 September 2021 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives